In JavaScript, Symbol is a primitive data type introduced in ES6 (2015). It is unique because every Symbol you create is guaranteed to be completely unique, even if you give it the same name.
They are unique and immutable data types that can be used as property keys in objects. Unlike strings, symbols create unique keys, which helps avoid naming collisions in object properties.
Symbols are often used to add unique property keys to an object that won't collide with keys any other code might add to the object, and which are hidden from any mechanisms other code will typically use to access the object.
That enables a form of weak encapsulation or a weak form of information hiding
Every Symbol() call is guaranteed to return a unique Symbol.
Every Symbol.for('key') call will always return the same Symbol for a given value of 'key'. When Symbol.for('key') is called, if a Symbol with the given key can be found in the global Symbol registry, that Symbol is returned.
Otherwise, a new Symbol is created, added to the global Symbol registry under the given key, and returned.
How would you use a Symbol to create a unique property key on an object to avoid name collisions?
What happens if you try to concatenate a Symbol with a string?
If you create two Symbols with Symbol('id'), are they equal? Explain why.
We have a library that relies on Symbol.iterator, but a custom object’s for…of loop isn’t working. How would you debug the issue?
When refactoring a codebase to replace string constants with Symbols for action types, what trade‑offs should you consider?
You need to expose a Symbol as part of a public API while keeping it hidden from consumers. How would you design that?
In a large application you want to use Symbols for private fields across many modules. What are the performance and tooling implications, and how would you mitigate them?
Design a plugin architecture where plugins can add metadata to core objects without clashing. How would you leverage Symbols, and what edge cases must you handle?
If you need to serialize objects that contain Symbol‑keyed properties for storage or network transfer, what strategy would you use and why?
Your organization is migrating from string‑based event names to Symbol‑based identifiers to guarantee uniqueness across teams. How would you plan the migration to minimize breakage and ensure backward compatibility?
When defining a public library, you want to expose well‑known symbols for extensibility but also keep internal implementation details private. How would you structure the module exports and documentation?
Consider a micro‑services environment where messages are routed based on Symbol identifiers. What risks does this pose and how would you keep Symbol definitions consistent across services?